This application relates generally to the operation of re-programmable non-volatile memory systems such as semiconductor flash memory, including management of the interface between a host device and the memory system, and, more specifically, to the efficient use of a data file interface rather than the common mass memory logical address space (LBA) interface.
Described herein are developments in various operations of a flash memory that are described in pending U.S. patent application Ser. Nos. 11/060,174, publication no. 2006/0184718 A1, 11/060,248, publication no. 2006/0184719 A1, and 11/060,249, publication no. 2006/0184720 A1, all filed on Feb. 16, 2005 naming either Alan W. Sinclair alone or with Peter J. Smith (hereinafter referenced as the “Prior Applications”).
Further developments are described in related U.S. patent applications of Alan W. Sinclair and Barry Wright, namely non-provisional applications Nos. 11/382,224, publication no. 2007/0033328 A1, and 11/382,232, now U.S. Pat. No. 7,450,420, and provisional applications Nos. 60/746,740 and 60/746,742, all filed on May 8, 2006, and non-provisional applications entitled “Indexing Of File Data In Reprogrammable Non-Volatile Memories That Directly Store Data Files,” application Ser. No. 11/459,255, publication no. 2007/0033375 A1, “Reprogrammable Non-Volatile Memory Systems With Indexing of Directly Stored Data Files,” application Ser. No. 11/459,246, publication no. 2007/0033374 A1, “Methods of Managing Blocks in NonVolatile Memory” application Ser. No. 11/459,268, publication no. 2007/0033332A1, and “NonVolatile Memory With Block Management,” application Ser. No. 11/459,2609 publication no. 2007/0033331 A1 all filed Jul. 21, 2006.
All patents, patent applications, articles and other publications, documents and things referenced herein are hereby incorporated herein by this reference in their entirety for all purposes. To the extent of any inconsistency or conflict in the definition or use of terms between any of the incorporated publications, documents or things and the present application, those of the present application shall prevail.
Data consolidation is treated differently herein than garbage collection and the two processes are implemented at least partially by different algorithms. When a file or memory block contains obsolete data, a garbage collection operation is utilized to move valid data of the file or block to one or more other blocks. This gathers valid data into a fewer number of blocks, thus freeing up capacity occupied by obsolete data once the original source block(s) are erased. In data consolidation, valid data of one partially filled block, such as is usually created as the result of writing a new file, are combined with valid data of another partially filled block. One or both of the original blocks that were the source of the data, now containing obsolete duplicate data, are then scheduled for garbage collection. Although queues are provided for scheduling individual garbage collection operations to recover memory storage capacity occupied by obsolete data, data consolidation preferably occurs when no garbage collection is scheduled and conditions are otherwise satisfactory for consolidation.
Rather than scheduling data consolidation of a newly written file right after the file is closed, data of a newly written file are maintained in the original blocks to which they were programmed after receipt from a host. This most commonly includes a block that is partially filled with the new data. Since it is not uncommon for a data file to be deleted or updated in a way that creates obsolete data, consolidation of the data of the partially filled block is postponed as long as possible after the file is closed. The file may be deleted without the need to relocate any data. Therefore, if the file is deleted or updated before such a consolidation becomes necessary, the consolidation is avoided. Such a consolidation can become necessary, as the memory becomes full, for there to be enough erased blocks for further programming of new data. But because the file based memory does not retain data files that have been deleted by the host, contrary to the case when a logical interface is used, the memory will usually have a sufficient number of erased blocks even though the consolidation is delayed. The time taken by the omitted consolidation is therefore saved, and the performance of the memory improved as a result.
There are several other developments in the direct file storage, described below, that may be summarized:
1. Once a file is closed, it is not added to the file garbage collection queue unless it contains obsolete data.
2. Garbage collection of a file does not create a common block that contains data from another file. Data for the file, which must be copied during the garbage collection, are programmed to the current program block for the file. The program block remains partially programmed at the end of the garbage collection.
3. When data must be relocated from a common block as a result of a file group in the block being made obsolete by deletion of a file, remaining valid data are relocated into an available space of a program block.
4. Movement of host data written directly into a full or portion of a program block is avoided.
5. During garbage collection of a file, data are relocated to a program block for the file. There is no dedicated intermediate copy block.
6. Data are transferred between the memory system controller buffer memory and the memory cell array in complete sectors of data. This allows the generation of an ECC during programming and checking of an ECC during data read.
7. The start of a data group or file group in a common block is aligned to the start of a metapage. On-chip copy may consequently be used for block consolidation. Data groups in program blocks have no specific alignment to physical structures.
8. A swap block within the flash memory is used to make a security copy of data held in the volatile controller buffer memory for an open file that is not active; that is, when the most recent write command relates to a different file. It may also be used as part of a virtual buffer structure, to allow the available buffer memory capacity to support a larger number of open files through the use of swap operations between them.
9. When a FIT file is moved to another FIT range because its current range overflows, the file data pointer in the directory is updated to reflect the new FIT range.
10. Data in a FIT update block for a FIT range is consolidated with data in the FIT block for the range when the amount of data for the range in the FIT update block exceeds a threshold value. This allows data for new files to be consolidated to a FIT block.
11. During compaction of a FIT update block, a FIT file for a closed file is relocated to the FIT block for its range if sufficient erased space exists. Otherwise, it is relocated to the compacted FIT update block.
12. A host may use write_pointer and read_pointer commands to control all files in a set to have equal size, the same as the size of a metablock, and may use close and idle commands to cause a file in the set to be consolidated into a single metablock immediately after the file is closed.
13. The set of host commands includes read and write commands for a specified fileID that include companion commands for the values of the Write_pointer and Read_pointer that give the memory addresses at which the commanded data write or read is to begin.